System and Method for Location-Based Transaction

ABSTRACT

A system and method for using at least location information to facilitate a transaction is provided. In one embodiment of the present invention, a mobile application operating on a mobile device is used to determine a location of the mobile device. Location information is then provided to a host device, where it is used to identify a second party. Information on the second party, including transactions offered, is then provided to the first party (e.g., via the mobile device, an intermediate device, and/or a device operated and/or owned by the second party). The first party can then interact with the mobile application to select or confirm at least one of the offered transactions. If the transaction is a purchase of goods/services, then a linked payment method may be charged. If the transaction is financial, then the first party may have to further provide authentication data (e.g., a PIN).

RELATED APPLICATIONS DATA

This application is a continuation of Ser. No. 15/620,110, which wasfiled on Jun. 12, 2017, which was a continuation-in-part of Ser. No.15/410,544, which was filed on Jan. 19, 2017, the subject matter ofwhich is incorporated by reference herein in its entirety.

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates to use of location information, along withother data, to carry out a transaction, and more particularly to anapplication operating on a mobile device (e.g., smartwatch, smartphone,etc.), the application being configured to acquire a location of themobile device and to use the acquired location, along with other data(e.g., user name, password, biometric data, time, etc.) to perform atransaction.

2. Description of Related Art

Mobile devices, such as smartphones and smartwatches, are becoming moreand more a part of our everyday lives. For years, there has been talk ofa “digital wallet,” where a person's mobile device replaces theirwallet, and can be used to pay for goods and services. Over the pastseveral years, this talk has become a reality with services such asApple Pay™. Apple Pay™ uses near field communication (NFC) technology tofacilitate a transaction between a person's smartphone and a merchant'spoint-of-sale (POS) device. However, as shown in FIG. 1, in order forthis transaction to take place, both the smartphone 300 and the POSdevice 400 must include NFC circuitry (e.g., 302, 402). NFC is a set ofcommunication protocols that enable two electronic devices in closeproximity (i.e., within four centimeters) to communicate with eachother. The NFC standard is based on existing radio-frequencyidentification (RFID) standards, and involves electromagnetic inductionbetween two loop antennas.

While NFC technology can be used to facilitate a transaction, it hasseveral drawbacks. First, NFC circuitry must be included in the mobiledevice, such as the smart phone or the smartwatch. Not only does suchcircuitry require a certain amount of real estate, but it adds costs tothe mobile device; costs that are ultimately born by the consumer.Second, NFC circuitry must also be included in the POS device (e.g., thecash register). Again, not only does such circuitry require a certainamount of real estate, but it adds costs to the POS device; costs thatare ultimately passed on to the consumer. And finally, the two devicesmust be in close proximity (less than four centimeters) in order tofunction properly.

In an effort to address some of these drawback, Samsung™ launchedSamsung Pay™. While Samsung Pay™ supports NFC technology, it alsosupports Magnetic Secure Transmission (MST) technology. MST technologyis technology that emits a magnetic signal that mimics the magneticstrip on a traditional payment card. As shown in FIG. 2, MST circuitry302′ in the smartphone 300′ sends a magnetic signal to the card reader402′ of the POS device 400′, emulating the swiping of a physical card.While MST technology has advantages over NEC technology (e.g., it canfunction with traditional POS devices, which include traditional cardreaders), it still requires MST circuitry 302′ to be included in thesmartphone 300′, increasing the smartphone size and cost, and requiresclose proximity to the card reader in order to function properly. Thisis extremely problematic with portable electronic devices becomingsmaller and smaller.

For example, smartwatches are becoming more and more popular, and moreand more advanced. With a smartwatch, however, real estate is extremelylimited, and there simply is not room for NFC and MST technology. And tothe extent such technology could be added, it would be to the detrimentof (e.g., in place of) other technology (e.g., technology that wouldallow the smartwatch to function autonomously, or without use of asmartphone). Furthermore, smartwatches also have a limited display, orare limited in the amount of information that can be provided to theuser.

Thus, it would be advantageous to develop a mobile solution thatovercame as least some of the foregoing drawbacks. For example, it wouldbe beneficial if a small mobile device, such as a smartwatch, couldfacilitate a transaction without requiring any additional hardwareand/or without having to be in close proximity to (or, in certainembodiments, even requiring) a POS device.

SUMMARY OF THE INVENTION

The present invention provides a system and method for using at leastlocation information to facilitate a transaction. Preferred embodimentsof the present invention include a host device in communication with atleast a mobile device (e.g., smartphone, smartwatch, tablet, etc.) via awide area network (WAN), such as the Internet.

In one embodiment of the present invention, the mobile device downloadsa mobile application (e.g., from the host device, a third party, etc.).The mobile application can then be opened and/or logged into by a firstparty (e.g., a user of the mobile device). Information provided by themobile application (e.g., user name, password, etc.) can then be used toidentify an account, which is preferably linked to at least one paymentmethod (e.g., user's credit card, user's debit card, user's PayPal™account, user's host account, etc.). The application then provides thehost device with other information, such as biometric data on the user,location information (e.g., the mobile device's location, informationthat can be used to determine the mobile device's location, etc.), time,etc., which can be used to authenticate the user (e.g., determinewhether the user is authorized to use (or is associated with) theidentified account) and identify a second party (e.g., a particularmerchant). The latter may be accomplished using a second party/locationmap stored in a database on the host device, where location informationprovided to the host is used to identify (e.g., lookup) a second partyin the database.

Once the second party is located, information concerning the firstand/or second party can then be provided to the first party via themobile device, an intermediate device (e.g., a device that allows themobile device to communicate with the host device), and/or a separate,network-enabled device (e.g., a device owned and/or operated by thesecond party). Information on the second party, which may be previouslyprovided by the merchant (e.g., a merchant device), stored in thedatabase on the host device, and linked (directly or indirectly) to thelocation information, may include the identity of the second party(e.g., merchant's name, address, phone number, logo, store hours, etc.),and/or goods/services provided by the second party (e.g., a menu ofgoods/services provided by the merchant, a particular good/servicepurchased by the first party, etc.). Information on the first party mayinclude the identity of the first party (e.g., name, email address,phone number, linked payment method, etc.) and/or goods/servicesselected (directly or indirectly) by the first party (e.g., directly viathe mobile application, or indirectly via an employee or agent of thesecond party).

The host device may then continue to communicate with the mobile device,the merchant device, any intermediate device, a third party financialdevice, and/or any separate, network-enabled device until thetransaction is completed. This further communication may involve thedisplay of options (or sub-options) to the first party (e.g., via themobile device, an intermediate device, and/or a separate,network-enabled device), the selection of at least one option (orsub-option) by the first party, the providing of authenticating data(e.g., a PIN, etc.) by the first party, authenticating theauthentication data (e.g., determining whether the provided PIN matchesa previously provided PIN, determining whether a provided Card SecurityCode (CSC) matches the numbers on the back of a credit or debit card,etc.), which may be performed by the host device, the merchant device,and/or the financial device, determining whether the transaction isbeing made within an acceptable window of time (e.g., during businesshours, during a time period allotted by the second party for the firstparty, etc.), transferring funds to complete the transaction (e.g., fromthe identified account to the merchant, etc.), and/or providingconfirmation of the transaction (e.g., to the mobile device, themerchant device, the separate, network-enabled device, etc.), which maytake place either before or after the actual funds have beentransferred.

By way of example, a user may walk into (or up to) a store or kiosk andopen and/or log into the mobile application. The host device may thenuse the login information to locate the user's account in the database,which may be linked to at least one payment method. The mobileapplication may then provide location information to the host device,where it is used to identify the store/kiosk. Information concerning thestore/kiosk (e.g., name, logo, etc.) may then be provided to the mobileapplication and displayed to the user. This allows the user to confirmthat the correct store has been located. The host device may thenprovide the user with a menu of goods/services offered at thestore/kiosk. This can be done via the mobile device, an intermediatedevice, and/or a separate, network-enabled device (e.g., a device ownedand/or operated by the second party). The user can then interact withthe mobile device to select at least one good/service. After theselection has been made and/or acknowledged by the user, the host devicemay provide the transaction (or acknowledgement) to the merchant device,charge the user's payment method (if needed), and provide a receipt tothe mobile application operating on the mobile device and/or themerchant device, which may include a separate, network-enabled device(e.g., Point-of-Sale (POS), Automated Payment System (APS), AutomatedTeller Machine (ATM), Set Top Box (STB), gaming device, etc.). If thetransaction is a purchase, the user can use the receipt to acquire thegood/service from the store/kiosk and/or show proof of purchase beforeleaving the store/kiosk. As mentioned above, such a method may require adetermination of whether the transaction is being performed during anacceptable window of time (e.g., during business hours, etc.). It mayalso require the user (including the mobile device) to be at aparticular location in order for the transaction to be processed. Inother words, location information can be used to both identify aparticular merchant (e.g., allowing the host to provide the user withinformation on the merchant, such as store name, hours of operation,available goods/services provided by the merchant, etc.) and toauthenticate the user (e.g., requiring the user to be inside or adjacentthe merchant's store/kiosk before the user can purchase goods/servicesfrom the merchant, etc.).

In another example, the host device may receive an order from themerchant device (e.g., an order that the user placed with a cashierwhile in the store, etc.). The location information provided by themobile application is then used to not only identify the store/kiosk buta pending order. In this example, the pending order is provided to themobile application. If the user acknowledges the order, then the user'spayment method is charged, and receipts are provided to the mobileapplication operating on the mobile device and the merchant device. Thereceipt would inform the merchant that the user has paid for the pendingorder. In this embodiment, it may not be necessary to determine whetherthe transaction is being performed during an acceptable window of time,as the second party's employee or agent (e.g., cashier, etc.) isinvolved in the transaction, ensuring that the transaction is takingplace during an appropriate time (e.g., during business hours, etc.). Asbefore, the location information can also function to authenticate theuser, requiring the user to be at a particular location in order for thetransaction to be processed. Such a feature would ensure that the mobiledevice is not being used to process a transaction from a remote (orunauthorized) location.

In yet another example, if there is more than one order pending, thehost device could either provide the mobile application with the pendingorders, requiring the user to select the order that is theirs, oranother method could be used to associate one of the pending orders tothe mobile application (or user's account). For example, the merchantcould enter a name (or other identifying information) that could be usedto identify the proper account, the user could enter identifyinginformation (e.g., order number, etc.) that could be used to identifythe proper order, or individual locations within the store could be usedto identify individual orders. For example, a location in front of afirst cashier could be used to link an account of a user standing atthat location to an order placed by the first cashier, etc.

In embodiments of the present invention, the mobile device may includeat least one transceiver configured to communicate with the host devicevia the Internet (e.g., either directly or indirectly, e.g., via anintermediate device) and to communicate with other devices in order toacquire location information and/or determine a user's location. Forexample, the transceiver(s) may be configured to communicate with thehost device (either directly or indirectly) via at least one satellite,at least one cell tower, and/or at least one wireless (Internet) device(e.g., using Bluetooth, WiFi, etc.). The transceiver(s) may also beconfigured to communicate with these devices to acquire locationinformation (e.g., using GPS, GSM (e.g., multilateration of radiosignals between cell towers), WiFi-based positioning, etc.). In analternate embodiment of the present invention, location information isprovided by at least one radio head in a distributed system, asdescribed in the co-pending patent application (Ser. No. 15/154,970),which is incorporated herein by reference.

A critical aspect of the invention is determining the location of theuser, or more particularly the user's mobile device. As discussed above,this may be the actual location of the device, a more general locationof the device, or a location of an intermediate device. This informationcan be used to authenticate the user and/or to identify at least oneother party (e.g., a merchant). In one embodiment of the presentinvention, with respect to the latter, the system only needs to identifyone from a plurality of parties (e.g., a plurality of stores, etc.). Forexample, if the device is located in (or in front of) a firststore/kiosk, then acts of commerce associated with the first store/kioskcan be provided to the user. Similarly, if the device is located in (orin front of) a second store/kiosk, then acts of commerce associated withthe second store/kiosk can be provided to that user.

In another embodiment of the present invention, location of the deviceis used to determine more than just the store in which the device islocated. In this embodiment it is further used to identify where insidethe store the device is located. For example, the device could be infront of a first checkout, a second checkout, etc. This embodimentallows multiple pending orders to be linked to the proper user, ormobile application. For example, if the user is standing in front of thefirst cashier, and the first cashier has just entered an order, then theorder can be associated with the user regardless of other orders enteredby other cashiers, or other applications operating on other mobiledevices within the store.

As discussed above, location information can also be used toauthenticate the user. For example, if the user is attempting to performan ATM transaction, the present invention can use location informationto ensure that the user (including the mobile device) is located near(or in front of) the ATM. Similarly, if the user is attempting toperform a store transaction, the present invention can use locationinformation to ensure that the user is located within (or in closeproximity to) the store. Not only would this prevent a user fromperforming a transaction from remote (or unauthorized) location, but itwould allow other security measures, such as security cameras at theauthorized location(s), to discourage fraudulent usage.

As discussed above, a second party/location map may be used (along withlocation information of the mobile device) to identify a particularsecond party. In one embodiment, this data is also used to authenticatethe user. In other embodiments, other data is further (or alternatively)used to authenticate the user. For example, a particular location (e.g.,X-Y coordinates) along with a first proximity (e.g., within a onehundred foot radius of the particular location) may be used to identifya second party. In one embodiment, this same data is used to identifyauthorized locations, or authenticate the user. In other embodiments,other data, perhaps more stringent data (e.g., within a 10 foot radiusof the particular location, within a 10 foot radius from a differentlocation, etc.), is used to identify authorized locations, orauthenticate the user. As such, the second party/location map mayinclude several fields, including information on the second party (e.g.,name, address, phone number, hours of operation, goods/servicesprovided, etc.), information that can be used to identify the secondparty (e.g., at least one location, a first proximity value, etc.),and/or information that can be used to identify authorized locations(e.g., at least one location, a second proximity value, etc.). Theuser's account may also be linked to at least one authorized location(e.g., at least one location, proximity data, etc.). This could be used,for example, to authenticate the user if the user is attempting to carryout a transaction from a remote location (e.g., from the user's home,etc.).

In certain embodiments of the present invention, the mobile device is asmartphone. However, in other embodiments, the mobile device may be awearable device, such as a smartwatch. In such embodiments, because theamount of information that can be displayed is limited (e.g., due to thesize of the wearable device), the mobile application and/or host devicemay be configured to display data to the first party using a pluralityof display devices, or display means. For example, in one embodiment ofthe present invention, the wearable device may be configured to displayfirst content on the mobile device and second content elsewhere. Forexample, the second content could be projected by the mobile device(e.g., using a projection device). By way of another example, the secondcontent could be displayed using a separate, network-enabled device. Forexample, if a wearable device (e.g., a smartwatch) is in communicationwith the host device via an intermediate device (e.g., a smartphone),then second content may be displayed on the intermediate device (or adisplay portion thereof).

In another example, second content may be displayed on a network-enableddevice owned and/or operated by the second party (or a display portionthereof). By way of example, a first party standing in front of an ATMmay open and log into the mobile application. Using the location of thewearable device, the mobile application (or host device) may identifythe ATM, and ask the first party (via the wearable device) to confirmwhether they would like to use the application to facilitate atransaction with the ATM. If the first party answers in the affirmative,the host device may then ask the first party (e.g., via the ATM display)to enter their PIN. The first party may then enter their PIN on thewearable device. If the provided PIN matches a predefined PIN, then thehost device may provide the first party with a plurality of options,such as withdraw money, make a transfer, etc. The options can either beprovide on the wearable device or provided on the ATM. However, if theoptions are provided on the ATM, the options should correspond toentries on the wearable device (e.g., press “1” for withdraw, “2” fortransfer, etc.). By selecting the appropriate option, which may resultin further sub-options (e.g., enter the amount to withdraw, etc.), themobile application, along with the ATM, can be used to facilitate afinancial transaction.

The same technology could be used to interact with other network-enableddevices. For example, if the first party is seated in front of a gamingdevice (e.g., slot machine, video poker, keno, lottery, etc.), themobile application could be used to add money to the gaming device,retrieve money from the gaming device, and/or play the gaming device. Ifa financial transaction is requested, then the sequence of steps may besimilar those use with the ATM. If, however, the wearable device is usedto play the game, the gaming device may be used to display options, andthe wearable device may be used to select from corresponding entries(e.g., press “1” for slots, “2” for video poker, etc.). By way ofanother example, if the first party is in a hotel room or on anairplane, the mobile application could be used to interact with atelevision or a related STB to select a movie to be played (e.g., theTV/STB could be configured to display a plurality of movie options, andthe wearable device could be configured to provide the user with aplurality of corresponding entries (e.g., press “1” for the first movie,“2” for the second movie, etc.)).

While wearable devices may have drawback (e.g., screen size, etc.), theyalso includes certain advantages. For example, because the wearabledevice is being worn by the first party, it could be used to capturebiometric data of the first party. For example, a camera feature on thedevice could be used along with facial and/or retina recognitionsoftware to identify/verify the first party, a microphone feature on thedevice could be used alone with voice recognition software toidentify/verify the first party, and/or a sensor feature on the device(e.g., capturing heart rate data, etc.) could be used to confirm thatthe wearable device is being worn while the mobile application is beingused to facilitate a transaction. By way of another example, the mobileapplication may use the sensor data (e.g., EKG, etc.), either alone ortogether with other data, to uniquely identify the first party. By beingable to confirm that the user has possession of the mobile device, is ata location of the transaction, knows the correct password, and exhibitscorrect (or matching) biometric data, the mobile application, along withthe host device, can be used to carry out sensitive transactions, suchas banking or other financial transactions. If the mobile deviceincludes a camera, the camera could further be used to capture a photoof the user while the transaction is being carried out. The photo couldthen be provided to the host and stored together with transactioninformation. Such use of the mobile device (e.g., as a security camera)should further detour fraudulent usage of the present invention.

A more complete understanding of a system and method for using at leastlocation information to facilitate a transaction will be afforded tothose skilled in the art, as well as a realization of additionaladvantages and objects thereof, by a consideration of the followingdetailed description of the preferred embodiment. Reference will be madeto the appended sheets of drawings, which will first be describedbriefly.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a prior art mobile device communicating with a POS deviceusing Near Field Communication (NFC) technology;

FIG. 2 depicts a prior art mobile device communicating with a POS deviceusing Magnetic Secure Transmission (MST) technology;

FIG. 3 depicts a system that uses at least location information tofacilitate a transaction in accordance with one embodiment of thepresent invention, said system comprising at least a host device incommunication with a mobile device, a merchant device, and/or a thirdparty device (e.g., payment device);

FIG. 4 depicts one embodiment of components included in the mobiledevice shown in FIG. 3;

FIG. 5 depicts exemplary devices that the mobile device may communicatewith in order to acquire location information;

FIG. 6 depicts another device (i.e., radio head) that the mobile devicemay communicate with in order to acquire location information;

FIG. 7 illustrates how a plurality of radio heads can be used toidentify the mobile device's location (e.g., x, y, and/or z).

FIG. 8 depicts a method for using at least location information tofacilitate a transaction in accordance with one embodiment of thepresent invention;

FIG. 9 depicts a method for using a mobile application to facilitate atransaction in accordance with one embodiment of the present invention;

FIGS. 10a-f depict exemplary screen shots of a mobile application beingused to facilitate a transaction in accordance with one embodiment ofthe present invention;

FIG. 11 illustrates use of the present invention to locate a mobiledevice within one of a plurality of establishments;

FIG. 12 illustrates use of the present invention to locate a mobiledevice within an establishment;

FIG. 13 depicts an exemplary smartwatch, which can be configured tofunction in accordance with alternate embodiments of the presentinvention;

FIGS. 14a-e depict exemplary screen shots of a mobile application beingused to facilitate a transaction in accordance with alternateembodiments of the present invention;

FIGS. 15a-c depict exemplary ways of providing information to a user ofthe smartwatch in accordance with alternate embodiments of the presentinvention;

FIG. 16 depicts yet another way of providing information to a user of amobile device, such as a smartphone or a smartwatch;

FIG. 17 depicts features that may be includes on a smartwatch, and usedto facilitate a transaction, including, sensors (e.g., heartratesensors, EKG sensors, etc.), a microphone, a camera, and/or projectiontechnology;

FIGS. 18a-c depict exemplary uses for the present invention, including,but not limited to, facilitating a banking transaction, a gamblingtransaction, and/or an entertainment transaction;

FIG. 19 depicts a method for using at least location information tofacilitate a transaction in accordance with another embodiment of thepresent invention;

FIG. 20 depicts a method for using at least one mobile applicationand/or program to facilitate a transaction in accordance with anotherembodiment of the present invention; and

FIG. 21 depicts an exemplary database for mapping users to userinformation, merchants to merchant information, and transactions totransaction information.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Preferred embodiments of the present invention include a host devicecommunicating with at least a mobile device (e.g., smartphone,smartwatch, tablet, etc.) via a wide area network (WAN), such as theInternet. It should be appreciated that while the present invention isdescribed in terms of facilitating a financial transaction (e.g., payingmoney in exchange for goods and/or services), the present invention isnot so limited, and can be used to carry out any type of transaction(e.g., acquire money from an Automatic Teller Machine (ATM), pay forparking at an Automated Pay Station (APS), retrieve a vehicle from aparking structure/lot (e.g., valet, car rental, etc.), play a movie/gameon a television (e.g., in a hotel room, etc.) (e.g., using a Set Top Box(STB)), add funds to (or acquire funds from) a gaming machine (e.g.,slot machine, video poker, provide money to a friend or family member,etc.), etc.).

FIGS. 1 and 2 depict prior art mobile devices that can be used tofacilitate financial transactions, with FIG. 1 using Near FieldCommunication (NFC) technology and FIG. 2 using Magnetic SecureTransmission (MST) technology. While both of these technologies can beused facilitate a financial transaction, they both have commondrawbacks. For example, both technologies require additional circuitry(and additional costs) and close proximity in order to facilitate atransaction.

The present invention addresses these drawbacks by using existingcircuitry (along with custom software) to facilitate a transaction. Inone embodiment of the present invention, as shown in FIG. 3, the mobiledevice 300 can be used to facilitate a transaction by using standardmobile device circuitry to communicate with a host device 10 over a widearea network (WAN) 20, such as the Internet. The host device may also bein communication with at least one merchant device 40, such as a POSdevice, and at least one third party device 50, such as a device at afinancial institution (e.g., a credit card company, PayPal™, a bank,etc.).

It should be appreciated that while FIG. 3 depicts the mobile device 30as a smartphone, and the merchant device 40 and the third party device50 as desktop computers, the present invention is not so limited. Forexample, use of any networked device (e.g., desktop computer, laptopcomputer, tablet, smartphone, smartwatch, network-enabled appliance,network-enabled POS device, network-enabled monitor, network-enabledtelevision, server, etc.), or combination thereof, by either party(customer, merchant, and/or financial institution), is within the spiritand scope of the present invention. It should also be appreciated thatthe present invention is not limited to a host device 10 that includesthe components depicted in FIG. 3. For example, a host device thatincludes fewer, additional, and/or different components is within thespirit and scope of the present invention.

In one embodiment of the present invention, as shown in FIG. 3, themobile device 30 downloads a mobile application (not shown) (e.g., fromthe host device, a third party, etc.). The mobile application, operatingon the mobile device 30, can then be opened and/or logged into, where itwill communicate with the host device 10 (e.g., via the web server 12and the WAN 20). Information provided by the mobile application andstored in the database 16 (e.g., user name, password, etc.) can then beused to identify the first party's (user's) account, which is preferablylinked to at least one payment method (e.g., user's credit cart, user'sdebit card, user's PayPal™ account, user's account on the host device,etc.). Other information, such as biometric data on the user, locationinformation (e.g., the mobile device's location, information that can beused to determine the mobile device's location, etc.), time, etc., maybe received from the mobile application and used (e.g., by theapplication 14) to authenticate the user (e.g., determine whether theuser is authorized to use (or is associated with) the identifiedaccount, determine whether the user is at an authorized location, etc.)and identify a second party (e.g., a particular merchant). The lattermay be accomplished using a second party/location map stored in thedatabase 16 (discussed below).

Once the second party is located, information concerning the secondparty can then be provided to the mobile application operating on themobile device 30, and displayed to the first party (user). Theinformation, which is preferably provided by the merchant device 40,stored in the database 16, and linked (directly or indirectly) to thelocation information, may include the identity of the second party(e.g., merchant's name, address, phone number, logo, store hours, etc.),goods/services provided by the second party (e.g., a menu ofgoods/services provided by the merchant, a particular good/servicepurchased by the first party, etc.), and/or goods/services requested bythe first party (e.g., a request taken by an agent/employee of thesecond party, for example, while the first party is within abrick-and-mortar location of the second party, etc.).

The host device 10 (or application 14 operating thereon) may thencontinue to communicate with both the mobile device 30 and/or the thirdparty device 50 until the financial transaction is complete, which mayinvolve communications between the host device 20 and the third partydevice 50 (e.g., to debit the first party's account with a third partyfinancial institution). Examples and details of how the invention may beused to facilitate a transaction will now be provided.

In one embodiment of the present invention, a user may walk into (or upto) a store or kiosk (e.g., which may include an ATM, APS, STB, etc.)and open and/or log into the mobile application. The host device 10 maythen use the login information to locate the user's account in thedatabase 16, which may be linked to at least one payment method. Themobile application may then provide location information to the hostdevice 10, where it is used to identify the store or kiosk in thedatabase 16. Information concerning the store or kiosk (e.g., name,logo, etc.) may then be provided to the mobile application and displayedto the user. This allows the user to confirm that the correct store orkiosk has been located.

In a first example, the application 14 may then provide the user with amenu of goods/services offered at the store or kiosk. The user can theninteract with the menu to place an order for at least one good/service.After the order has been placed and/or acknowledged by the user, theapplication 14 may provide the order to the merchant device 40, chargethe user's payment method (e.g., after the order has beenacknowledgement by the merchant, etc.) via the third party device 50,and provide a receipt to the mobile application operating on the mobiledevice 30 and/or merchant device 40. The user can then use the receiptto acquire the good/service from the store or kiosk and/or show proof ofpurchase before leaving the vicinity.

In a second example, the application 14 may receive an order from themerchant device 40 (e.g., an order that the user placed with a cashierwhile in the store, outside of a kiosk, etc.). The location informationprovided by the mobile application is then used to not only identify thestore or kiosk but a pending order. The pending order would be providedto the mobile application. If the user acknowledges the order, then theuser's payment method would be charged (e.g., via the third party device50), and receipts would be provided to the mobile application operatingon the mobile device 30 and the merchant device 40. The receipt wouldinform the merchant that the user has paid for the pending order, andcan now provide the user with the corresponding good/service.

In the second example, if there is more than one order pending, the hostdevice could either provide the mobile application with the pendingorders, requiring the user to select the order that is theirs, oranother method could be used to associate one of the pending orders tothe user's account. For example, the merchant could enter a name (orother identifying information) that could be used to identify the properaccount, the user could enter identifying information (e.g., ordernumber, etc.) that could be used to identify the proper order, orindividual locations within the store could be used to identifyindividual orders. For example, a location in front of a first cashiercould be used to link an account of a user standing at that location toan order placed by the first cashier, a location in front of a secondcashier could be used to link an account of a user standing at thatlocation to an order placed by the second cashier, etc.

It should be appreciated that other information may be used inconjunction with location information to identify a particular merchantand/or pending order, or to determine whether the requestedgoods/services should be provided. For example, to identify a pendingorder, time or a time period (e.g., a fifteen second window, etc.) maybe used along with location information. In other words, an order thatwas placed within fifteen seconds of a request to pay by the mobileapplication is more likely the correct order than an order that wasplaced five minutes ago. By way of another example, certaingoods/services may only be available during a particular window of time.For example, a request to purchase a particular item from a store thatis only open from 9:00 AM to 5:00 PM may only be accepted (or processed)if the request is received at an acceptable time (i.e., between 9-5). Byway of another example, a first party (e.g., tenant, real estate agent,etc.) may only be able to unlock a network-enabled door (or a doorhaving a network-enabled lock) (e.g., to a hotel room, a house for sale,etc.) owned, controlled, or operated by a second party (e.g., hotelmanager, relator, etc.) during a particular window of time, where thewindow of time is allocated by the second party for the first party.This would allow, for example, a guest to have access to a hotel room ona day, a real estate agent to have access to a house for sale during aparticular hour, etc. The same technology could be used to allow accessto, or operate any rental, regardless of whether the rental is astructure (e.g., a hotel room, etc.), a device (e.g., a vehicle, etc.),or a service (e.g., a pay-per-view movie, etc.).

It should also be appreciated that location information may includeinformation previously acquired (e.g., before the user enters thestore). This would allow the present invention to operate when themobile device is unable to acquire location information at the time apurchase is being made/confirmed. It should further be appreciated, asdiscussed above, that the present invention is not limited tofacilitating financial transactions at a store. For example, the presentinvention could be used to acquire money from an ATM (e.g., whilestanding in front of the ATM, using the mobile device to request funds),order a movie in a hotel room (e.g., while sitting in the hotel room,using the mobile device to select the movie), add funds to (or acquirefunds from) a gaming device, such as a slot or video poker machine(e.g., while seated in front of the gaming device, using the mobiledevice to facilitate the transaction), pay for a service at an APS(e.g., while standing (or parked) in front of the APS, using the mobiledevice to pay an amount owed), provide money to a friend or familymember, etc.

FIG. 4 illustrates components that may be included in the mobile device,such as a display 32, processor 34, memory 36, input 38, andtransceiver(s) 50. In one embodiment of the present invention, thememory 36 may be configured to store a mobile application (e.g.,downloaded from the host device, a third party, etc.), data on the firstparty (e.g., their account and information linked thereto (e.g., username, password, biometric data, payment method, etc.), data on thesecond party (e.g., their name, address, telephone number, transactionsoffered, pending transactions, etc.), data that can be used to identifya second party based on location information (e.g., at least onelocation, proximity data, etc.), and/or at least one authorized location(e.g., for the first party, the second party, etc.). The transceiver(s)may be configured to communicate with the host device via the WAN and tocommunicate with other devices in order to acquire location informationand/or determine a user's location. For example, as shown in FIG. 5, thetransceiver(s) 50 may be configured to communicate with the host devicevia at least one satellite 52, at least one cell tower 54, and/or atleast one wireless (Internet) device (e.g., using Bluetooth, WiFi,etc.). The transceiver(s) 50 may also be configured to communicate withthese devices to acquire location information (e.g., using GPS, GSM(e.g., multilateration of radio signals between cell towers), WiFi-basedpositioning, etc.). It should be appreciated that the term locationinformation, as used herein, may be the actual location of the device(e.g., x, y, and/or z coordinates), an estimated or approximate locationof the device, or information that can be used to acquire or estimatethe location (or approximate location) of the device. It should also beappreciated that the present invention is not limited to any particularmethod for determining location, and all methods generally known tothose skilled in the art are within the spirit and scope of the presentinvention. For example, in one embodiment of the present invention, themobile device may acquire location information from a network device,such as radio head. Such a system is disclosed in co-pending patentapplication entitled “Multi-Standard in Building Mobile Radio AccessNetwork,” filed on May 14, 2016 (Ser. No. 15/154,970), the contents ofwhich are incorporated herein by reference. In particular, thedisclosure of how a plurality of radio heads, located throughout abuilding can be used to provide location information on a mobile deviceis incorporated herein by reference.

Such a system is shown in FIG. 6, where a distributed system is used todetermine a location of a mobile device. Such a system includes at leastone mobile device 30 and at least one centralized device (e.g.,interface gateway 106 and/or radio head 102 d) in communication with aplurality of radio heads (e.g., 102 a, 102 b, 102 c). The centralizeddevice may be configured to recognize when the mobile device 30 hasentered a particular service area (e.g., entered a particular building).As the mobile device 30 moves around the service area (e.g., from floorto floor of the building), the mobile device may communicate withdifferent radio heads (e.g., 102 a, 102 b, 102 c). It is during thiscommunication that the radio head can inform the mobile device 30 and/orthe centralized device (e.g., interface gateway 106 and/or radio head102 d) of the mobile device's location (e.g., x, y, and/or zcoordinates). The mobile device's location can then be provided to thehost by the mobile device (as previously discussed), or by thecentralized device (via a separate communicate with the host device orby intercepting and modifying the mobile device's communication with thehost device).

As shown in FIG. 7, radio heads can use received power to determine thelocation of a mobile device. The received power level from a particularmobile device is measured by a plurality of radio heads 102. Since theabsolute transmitted power by the mobile device is unknown, the relativereceived signal strength at the radio heads are compared and thelocation of the mobile device can be estimated based on the relativedistances from the radio heads. In another embodiment, a time of arrivalapproach can be used (either alone or in addition a received powerapproach) to locate the position of the mobile device. In this layout,radio heads 102 will look for a special signal or signal feature andcreate a timestamp of the signal feature arrival. Using the travel timeof signals traveling through air at approximately 1 ns/ft over adistance between the device and the radio head 906, the relativeposition of the mobile device is determined. With respect to each radiohead, its position could be programmed during installation for maximumaccuracy, but the techniques described above, namely based on powermeasurement and time-of-arrival measurement, can also be applied for theradio heads to determine their own relative positions. In yet anotherembodiment (described in further detail in the co-pending application),sensors can be used to monitor the transmission from the radio head(s)102. This extra capability would allow the location measurements toremain accurate even if the radio heads are moved from the manuallyentered positions at installation.

It should be noted that the location information provided by the radioheads not only give latitude and longitude coordinates for each mobiledevice, but also floor information, allowing a user to be even moreprecisely located by including information about their altitude. Thisinformation is particularly useful when facilitating a transaction in amulti-floor structure. As discussed above, the location informationcould be conveyed from the mobile device to the host, directly, or fromthe centralized device (e.g., interface gateway 106 and/or radio head102 d) to the host device. In other words, the centralized device (or aportion thereof) could be used to provide location information to thehost device, similar to how 911 communications are described in theapplication incorporated by reference. This can be done by either aseparate communication or by intercepting and modifying the mobiledevice's communication. Once the host has the location information, itcan function as previously discussed (i.e., with the merchant and mobiledevices).

With reference to FIG. 4, it should be appreciated that a mobile deviceoperating in accordance with embodiments of the present invention mayinclude additional, fewer, or different components. For example, amobile device that further includes a dedicated GPS processor is withinthe spirit and scope of the present invention. Further, a mobile devicethat includes at least one input 38, such as a keyboard (providing hardkeys), touchscreen (providing soft keys), camera, and/or microphone isalso within the spirit and scope of the present invention. Finally,while the transceiver(s) 50 may be configured to communicate with a hostdevice via at least one satellite 52, at least one cell tower 54, and/orat least one wireless (Internet) device 56, the communication path maynot be so direct. For example, the mobile device may be configured tocommunicate with the host device via at least one other device (i.e., anintermediate device). By way of example, a smartwatch may becommunicating with a smartphone via Bluetooth or WiFi, which in turn iscommunicating with the host via a separate communication link (see,e.g., FIG. 5). In such an embodiment, the mobile application (or hostdevice in communication therewith) could use location information ofeither device to facilitate a transaction. This is due to the closeproximity of the smartwatch (e.g., mobile device) and the smartphone(e.g., intermediate device).

One method of using location information to facilitate a transaction isdepicted in FIG. 8. Starting at step 800, login information is receivedat step 802. Login information may include user name and password, ormore secure information such as biometric data of the first party (e.g.,data on the user's fingerprints, iris, retina, facial features, speechrecognition, EKG, etc.). Login information may also include a uniquekey, or a key unique to the mobile application and/or mobile device. Thekey could be either communicated or used to encode/decode and/orencrypt/decrypt communications between the mobile application and thehost device. Once received, the login information can be used to locatethe first party's account. The first party's account is an account thatis linked to the mobile application, the mobile device, and/or at leastone payment method (e.g., the user's credit card, debit card, etc.). Thelocation of the mobile device is then determined at step 804. Locationcan be determined by the mobile application, by the host device based oninformation provided by the mobile application, or by informationprovided by a third party (e.g., the centralized device in a distributedsystem, etc.). Once determined, location is then used to identify asecond party (e.g., a merchant, a store, a kiosk, etc.) at step 806.This may be accomplished using a second party/location map stored on thehost device or information available by a third party (e.g., GoogleMaps™, etc.).

At step 808, a determination is made as to whether the second party islinked to a pending act of commerce (e.g., a pending order for goodsand/or services). Pending acts of commerce are generally orders forgoods/services that may or may not be linked to time or a time period(e.g., within a thirty second window, etc.). If the answer is “yes,”then a determination is made at step 810 on whether there is more thanone order pending. If the answer is “no,” then the first party'saccount, or payment method linked thereto, is charged for the order atstep 816. A receipt is then provided to the mobile application and/orthe merchant device at step 818 ending the method at step at 820.

If at step 808, the answer is “no,” then a menu of available acts ofcommerce (e.g., goods and/or services provided by the second party) areprovided to the mobile application at step 814. The first party (user)can then select a particular act of commerce that the user would like topurchase at step 812, and the first party's account (or payment methodlinked thereto) is charged at step 816. A receipt is then provided tothe mobile application and/or merchant device at step 818, ending themethod at step 820.

If at step 810, the answer is “yes,” then the first party (user) mayselect their order at step 812. Alternatively, the host may select thecorrect order by associating data received from the merchant deviceand/or the mobile application (e.g., user name, order number, specificlocation (e.g., cash register one), time period, etc.) with a particularorder. The first party's account (or payment method linked thereto) isthen charged for the selected/identified order at step 816. A receipt isthen provided to the mobile application and/or merchant device at step818, ending the method at step 820.

It should be appreciated that the present invention is not limited tothe steps illustrated in FIG. 8, and fewer, additional, or differentsteps are within the spirit and scope of the present invention. Forexample, if only the first party is allowed to place an order (e.g., viathe application), then steps 808 and 810 may be deleted, with step 814being located between steps 806 and 812. By way of another example, ifonly the second party is allowed to place an order (e.g., via themerchant device), then step 814 may be deleted. By way of yet anotherexample, before charging the first party's account (or payment methodlinked thereto), the first party may be required to acknowledge theorder before their account is charged. By way of yet another example, ifthe first party is allowed to place an order at step 812, the method mayalso determine whether the current time is within a particular timewindow. For example, if a store or kiosk is only open from 9-5, then adetermination may be made as to whether the current time (e.g., timethat the transaction is being made, etc.) is within this window of time.This step may be performed before step 812 (e.g., immediately beforestep 812, before step 814, etc.) or after step 812, before the accountis charged at step 816. It should also be appreciated that the presentinvention is not limited to the steps being performed in the orderillustrated in FIG. 8. For example, the mobile application coulddetermine the device's location before login information is received.

As previously discussed, location information can also be used (alongwith biometric data) to authenticate the user. For example, the host mayensure that the user is at a particular (e.g., authorized) locationbefore a transaction can be processed. For example, if the user isattempting to perform an ATM transaction, the host may require that theuser (along with the mobile device) be located in front of the ATM.Similarly, if the user is attempting to perform a store transaction, thehost may require that the user (along with the mobile device) be locatedinside the store. When dealing with a merchant, such a feature could beused to prevent transactions from remote (or unauthorized) locations, orallow transactions from local (or authorized) locations. For example,such a feature may allow a user to withdraw money from an ATM only whenthe user is standing in front of the ATM, allowing the user to be imagedby security cameras. By way of another example, the host may allow theuser to perform remote transactions only when the user is located at anauthorized location (e.g., the user's home, etc.). Maps for storing suchinformation are discussed in greater detail below.

One method of using a mobile application to facilitate a transaction isdepicted in FIG. 9. Starting at step 900, the application is open atstep 900. The first party (user) may then enter login information atstep 904. As discussed above, the login information may include username, password, biometric data, location information, etc., and mayfurther require the use of a unique key. At step 906, the first party(user) would be provided with information associated with the location.This may include data on the second party (e.g., store name, logo, etc.)and/or data on acts of commerce (goods and/or services) provided by thesecond party. By providing data on the second party, the user canconfirm that the application is functioning properly (e.g., the storeidentified is the one that they are in, etc.). Data on the acts ofcommerce can either be a menu of available goods and/or services and/orat least one pending order. At steps 908 a determination is made as towhether multiple acts of commerce are provided (e.g., a menu of goodsand/or services, multiple pending orders, etc.) or whether a single actof commerce is provided (e.g., only one good or service is available,only one pending order, etc.). If the answer is “yes,” then the firstparty (or in an alternate embodiment, the host) must select one act ofcommerce at step 910. If the answer is “no,” then no selection isnecessary. At step 912, the single act of commerce (as provided orselected) is acknowledged. If the act (or order) is not acknowledged,then the method stops at step 916. However, if the act (or order) isacknowledged, then the first party's account (or payment method linkedthereto) is charged at step 914, ending the method at step 916.

It should be appreciated that the present invention is not limited tothe steps illustrated in FIG. 9, and fewer, additional, or differentsteps are within the spirit and scope of the present invention. Forexample, a receipt or proof of purchase may be provided to the mobileapplication and/or merchant device after step 914. By way of anotherexample, the user may need to select an option (e.g., “pay now,” etc.)to trigger matching the location with a particular act of commerce. Thismay be performed before, after or during step 906 and would allow thesystem to more closely synch the placing of an order (e.g., by acashier) and a request for payment (e.g., by the user). By way of yetanother example, the user may have the option of selecting a time forwhen the act of commerce should be performed. This would allow, forexample, the first party to schedule a future act of commerce, and mayrequire the host device determining whether the selected time is withinan acceptable window of time (e.g., during business hours, etc.). Itshould also be appreciated that the present invention is not limited tothe steps being performed in the order illustrated in FIG. 8.

FIGS. 10a-10f depict exemplary screen shots of a mobile applicationbeing used to facilitate a transaction. For example, as shown in FIG.10a , a Key2Mobile™ (or other owner of the mobile application) loginscreen may be provided to the first party. In this example, the firstparty enters a user name and password. However, other verifyinginformation may be provided or used including biometric data (e.g.,fingerprint, iris, retina, facial features, speech recognition, EKG,etc.), a unique key (which may be entered or stored on the mobile deviceand used to either uniquely identify the mobile application and/or or toencode/decode and/or encrypt/decrypt communications between the mobileapplication and the host device), etc. Once the first party logs intothe application, the application may determine a location for the mobiledevice, which may be the actual location, or an approximate (orestimated) location, and may be acquired using one or more knowntechniques (e.g., using communications with at least one cell tower,satellite, radio head, etc.).

Once the location has been determined, it can be used (either alone ortogether with other information, such as time, etc.) to authenticate theuser (or transaction) and to identify a second party, such as a merchantor an entity associated with the location. Once the second party isidentified, it can be provided to the user via the application (see,e.g., FIG. 10c , “CompanyName” with logo). The user can also be providedwith options associated with the second party. In one embodiment of thepresent invention, as shown in FIG. 10c , this may include high-leveloptions that can be facilitated by the mobile application. For example,assume a user walks into a cellular telephone store. If he/she is thereto change their cellular telephone plan, he/she may select the “performaction” 1010 option, which may include the sub-category “change cellulartelephone plan” (not shown). The host device would then notify the storeof this request for assistance. If the user is there to pay his/hercellular telephone bill, the user could select the “make payment” 1008option. The host could then use information stored in the database orinformation entered by the user (e.g., the user's telephone or accountnumber) to make a payment. If the user is there to make a purchase,he/she may select the “make purchase” option. The user may then beprovided with at least one act of commerce that the second party offers,depending on how the system, application, and/or second party isconfigured. If there is a pending order for the user (e.g., if the userjust placed an order with a cashier), then a single act of commerce maybe provided to the user. Otherwise, the user may be provided with a menuof acts of commerce offered by the second party. This is shown in FIG.10d , where the user can select from “item number 1” 1012, “item number2” 1014, and “item number 3” 1016.

The “selected item” 1018 may then be provided to the user, along with an“acknowledge purchase” 1020 option (see FIG. 10e ). If the useracknowledges the purchase, the host device will be notified, the paymentmethod linked to the user's account will be charged, and a proof ofpurchase (e.g., receipt) will be provided to the user and/or merchant,thereby completing the financial transaction (see FIG. 10f ). It shouldbe appreciated that the present invention is not limited to the screenshots depicted in FIG. 10a-f , as the screen shots are merely exemplary.Depending on (i) how the system is configured, (ii) the informationavailable to the host on the second party, and (ii) options selected bythe first party, will dictate the type of information provided to theuser and/or merchant and the order in which the information is provided.

A critical aspect of the invention is determining the location of theuser, or more particularly the user's mobile device. As discussed above,this may be the actual location of the device or a more general locationof the device. In one embodiment of the present invention, as shown inFIG. 11, the system only needs to determine which second party (e.g.,store, etc.) the device is located. If the device is located in the shop1102, then acts of commerce associated with that second party can beprovided to the user. Similarly, if the device is located in thesupermarket 1104, then acts of commerce associated with that secondparty can be provided to that user. The same holds true for the shops1106 and 1108.

In another embodiment of the present invention, as shown in FIG. 12,location of the device is used to determine more than just the secondparty. In this embodiment it is used to identify where inside the secondparty the device is located. For example, the device could be in frontof a first checkout 1202, a second checkout 1204, or a third checkout1206. This embodiment allows multiple pending orders to be linked to theproper user, or mobile application operating on a mobile device. Forexample, if the user is standing in front of the first checkout 1202,and the cashier at the first checkout just entered an order, then thatorder can be associated with the user regardless of other orders enteredby the second or third checkout 1204, 1206, or other applicationsoperating on other mobile devices.

While specific embodiments have be provided for using at least locationinformation to facilitate a transaction, the present invention is not solimited. For example, as discussed above, the present invention could beused to access secure information (e.g., from a database on a hostdevice (see, e.g., FIG. 3 at 10 and 16), from a second computer via ahost device (see, e.g., FIG. 3 at 10 and 40), etc.). For example, a usermay be allowed to access, or be provided with, secure information if theuser is in possession of, or using, a verified (mobile) computing deviceand verified login, biometric, and/or location data isprovided/acquired. In other words, a remote computing device (e.g., hostdevice, second computing device, etc.) may be configured to providesecure information to a particular (mobile) device (e.g., one that isrunning a particular (mobile) application, one that has at least oneunique key (e.g., for encoding, decoding, encrypting, decrypting, etc.),etc.) only if the remote device receive proper login data (e.g., username, password, etc.), proper biometric data (e.g., biometric data(e.g., fingerprint data, iris data, speech data, EKG, etc.)corresponding to the user, etc.), and/or proper location data (e.g.,confirming that the (mobile) computing device is at a proper orauthorized location). For example, a host device for a law firm may onlyallow devices that are located within the law firm to accessconfidential, sensitive, and/or privileged information.

By way of another example, the present invention could be used fordelivery confirmation of goods. For example, a delivery person (ordrone, robot, etc.) may only leave goods with an individual if theindividual is using a particular (mobile) device (e.g., one that isrunning a particular (mobile) application, one that has at least oneunique key, etc.) and the host device receives/confirms proper login,biometric, and/or location data. If the host device confirms that thepassword and/or biometric data matches the individual (e.g., user name,etc.), and/or the location of the (mobile) device matches the order(e.g., corresponding to the goods), then delivery confirmation isprovided. This may be accomplished by providing a receipt (e.g.,barcode, etc.) to the individual's (mobile) device, which can bepresented to (and scanned by) the delivery person (or drone, robot,etc.) for delivery confirmation. It should be appreciated that whilelocation data may be used to facilitate a transaction, it may also (orinstead) be used by the delivery person, drone, robot, etc. to locatethe individual or to where the goods should be delivered. In anotherembodiment, a receipt may also (or instead) be provided to a mobiledevice carried by the delivery person. If the goods are electronic innature, delivery confirmation may also (or instead) be provided to thegoods, where delivery confirmation results in at least one functionbeing performed. For example, in the case of a vehicle, the vehicle mayrequire delivery confirmation before it allows entry and/or operatesproperly. By way of another example, in the case of a computing device(laptop, smartphone, etc.), the device may require delivery confirmationbefore it operates properly.

As discussed above, in one embodiment of the present invention, themobile device may be a wearable device, such as a smartwatch (see FIG.13). While a wearable device may function similarly to the moregeneralized mobile device (discussed above), it may differ in howinformation is provided to the user. This is due to the fact thatwearable devices are generally small, and therefore have limited screensizes. As such, the amount of information that can be presented to (orreceived from) a user is limited.

FIGS. 14a-14e depict exemplary screen shots of a mobile applicationbeing used on a wearable device to facilitate a transaction. Forexample, as shown in FIG. 14a , a simplified login screen may beprovided to the first party. In this example, the first party enters aPersonal Identification Number (PIN) or password associated with theuser's account. However, other verifying information may also (oralternatively) be provided and/or used including name, biometric data(e.g., fingerprint, iris, retina, facial features, speech recognition,EKG, etc.), a unique key (which may be entered or stored on the mobiledevice and used to either uniquely identify the mobile applicationand/or or to encode/decode and/or encrypt/decrypt communications betweenthe mobile application and the host device), etc. Once the first party'saccount is identified, the application may determine a location for themobile device (see FIG. 14b ), which may be the actual location, or anapproximate (or estimated) location, and may be acquired using one ormore known techniques (e.g., using communications with at least one celltower, satellite, radio head, etc.).

Once the location has been determined, it can be used (either alone ortogether with other information, such as time, etc.) to authenticate theuser (or transaction) and to identify a second party, such as a merchantor an entity associated with the location. Once the second party isidentified, it can be provided to the first party via the application(see, e.g., FIG. 14c , “CompanyName” with logo), along with an option1404 to acknowledge the second party (i.e., acknowledge that theidentified company is the correct company). In one embodiment, the firstparty (e.g., wearing the wearable device) may approach (physically) thesecond party (or an employee, agent, or kiosk thereof or associatedtherewith) and make a purchase (e.g., via a POS device). The purchasemay then be provided to the host device (e.g., from the POS device), anddisplayed to the first party (e.g., via a “Transaction” icon 1406). Thefirst party may then have the option of confirming the order (e.g., viaan “Acknowledge Transaction” button 1408). If the order is confirmed,then a payment method (e.g., linked to the first party's account,selected by the first party from a list of available options (notshown), etc.) may be charged (if appropriate), and a receipt will beissued to the first party, which may include transaction information1406 and/or a unique barcode 1410. Similar information may also beprovided to the second party (or the POS device), confirming thatpayment has been received, and that goods/services (as purchased,requested, etc.) should be rendered.

It should be appreciated that the present invention is not limited tothe screen shots depicted in FIG. 14a-e . Depending on (i) how thesystem is configured, (ii) the information available to the host on thesecond party, (iii) the type of mobile device used (the mobileapplication may be configured to detect the type of mobile device andshare this information with the host device), and (iv) options selectedby the first party, will dictate the type of information provided to theuser and/or merchant and the order in which the information is provided.For example, instead of interacting with an employee, agent, or kiosk tomake a purchase, the first party may use the mobile application toselect at least one good/service from a plurality of goods/servicesoffered by the second party. To do this, the application may provide thefirst party with the plurality of goods/services offered by the secondparty. Depending on the type of device that is being used (e.g.,smartphone, smartwatch, etc.), the plurality of goods/services may beshown on one screen (see, e.g., FIG. 10d ), or may be cycled through bythe first party (e.g., by clicking a “next” or “->” button(s)) (notshown)). Once a selection has been made, the first party may be allowedto confirm the purchase (see, e.g., FIG. 14d ) and/or may receive areceipt for the purchase (see, e.g., FIG. 14e ).

As mentioned above, when it comes to a wearable device, screen size maybe limited, and may thereby limit the amount of information that can bedisplayed to the first party at one time. As shown in FIG. 15a , thewearable device 1300 may be configured to display both first and secondcontent 1502, 1504 on the device's screen (either simultaneously, asshown, or sequentially, as described above). Also, or alternatively, thesecond content 1504 could be displayed on the device's screen, while thefirst content 1502 is displayed elsewhere (or visa versa). For example,as shown in FIGS. 15b and 15c , the first content 1502 could beprojected using a projection device, e.g., onto a surface, such as theuser's hand, the user's wrist, a wall, a table, or a windshield, or intothe air (e.g., as a hologram). This can be accomplish using technologydeveloped by Samsung™ (e.g., Galaxy Beam™), Apple™ (e.g., Miroir HDProjector™), Cicret™ (e.g., Bracelet™), Microsoft™ (e.g., HoloLens™),Virtual Presence™, Magic Leap™, Daqri Holographics™, and Holoxia™, toname a few.

It can also be accomplished using a separate display device. Forexample, if a wearable device (e.g., a smartwatch) is in communicationwith the host device via an intermediate device (e.g., a smartphone),then second content may be displayed on the wearable device's screen,and first content may be displayed on the intermediate device's screen(or visa versa). In another example, as shown in FIG. 16, a wearabledevice 1300 (e.g., a smartwatch, etc.), which is connected to the hostdevice 10 via a WAN 20, may be configured to display the second content1504, while the first content 1502 is displayed on a network-enableddevice 1600 (or visa versa). In other words, information that is to bepresented to the first party can be done so using the wearable device1300 and/or the network-enabled device 1600, which may be owned and/oroperated by the first party, the second party, or a third party.

For example, as shown in FIG. 18a , an ATM may be configured to displaythe first content (e.g., data on the first party (e.g., John Smith,accounts held by John Smith, etc.), the second party (e.g., Bank ofAmerica, etc.), goods/services offered by the second party (e.g.,Withdraw Funds, Transfer Funds, etc.), and/or the first party'stransaction request (e.g., Withdraw $20 from John Smith's checkingaccount, etc.). The first party could then use the wearable device tofacilitate the transaction, where the wearable device is configured todisplay the second content (e.g., data on the first party, second party,goods/services offered by the second party, the first party'stransaction request, data related thereto, etc.). By way of exampleonly, a first party, standing in front of an ATM, may open and log intothe mobile application. Using the location of the wearable device, themobile application may identify the ATM, and ask the first party (viathe wearable device's display) to confirm whether they would like to usethe application to facilitate a transaction with the ATM (see, e.g.,FIG. 14c ). If the first party answers in the affirmative, the ATM maythen ask the first party (via the ATM's display) to enter their PersonalIdentification Number (PIN). The first party may then enter their PIN onthe wearable device (see, e.g., FIG. 14a ). If the provided PIN matchesa predefined PIN (as determined by the host device, the ATM, thefinancial institution, etc.), the host device may then provide the firstparty with a plurality of options, such as withdraw money, make atransfer, etc. The options can either be provide on the wearable device(see, e.g., FIG. 10d ) or provided on the ATM. However, if the optionsare provided on the ATM, the options should correspond to entries on thewearable device (e.g., press “1” for withdraw, “2” for transfer, etc.).By selecting the appropriate option, which may further require selectingthe appropriate sub-option (e.g., enter the amount to withdraw, etc.),the wearable device may ask the first party to confirm the requestedtransaction (see, e.g., FIG. 14d ). A receipt may then be provided tothe first party (e.g., via the wearable device (see, e.g., FIG. 14e ),via a printout from the ATM, etc.), and the requested transaction isperformed (e.g., $20 is dispensed from the ATM, etc.).

As shown in FIG. 18b , the same technology could be used to interactwith a gaming device, such as a slot machine. For example, while thefirst party is seated in front of a gaming device, the mobileapplication could be used to add money to the gaming device (instead ofinserting money or a voucher), retrieve money from the gaming device(instead of dispensing money or a voucher), and/or play the gamingdevice. If a financial transaction is requested, then the sequence ofsteps may be similar to those used on an ATM (see above). If, however,the wearable device is used to play the game, the gaming device may beused to display options, and the wearable device may be used to selectfrom corresponding entries (e.g., press “1” for slots, “2” for videopoker, etc.). It should be appreciated that, depending on the level ofinteraction, the wearable device may allow the first party to selectfrom corresponding sub-entries. For example, if the gaming device is (oris functioning as) a slot machine, the first party may press “1” (or“spin”) to spin the wheels. If the gaming device is (or is functioningas) a video poker machine, then the first party may press any number (orbutton) to deal the cards, press a corresponding number to hold a card(e.g., press “1” to hold the first card, “2” to hold the second card,etc.), and any other digit (“0,” “6-9,” “#,” or “*”) to deal replacementcards.

As shown in FIG. 18c , the same technology could be used to interactwith a network-enabled monitor, a network-enabled television, or anetwork-enabled Set Top Box (STB) connected to a television. Forexample, while the first party is in a hotel room or on an airplane, themobile application could be used to watch a movie, play a video game,etc. If the first party wants to watch a movie, the TV (or STB) mayprovide the first party with a plurality of options 1806, 1808. Asbefore, the wearable device may be used to select from correspondingentries, which may be individual movies (e.g., press “1” for the firstmovie, “2” for the second movie, etc.), or may allow the first party todrill down to a plurality of movies (e.g., press “1” for new releases,“2” for still in theater, etc.). It should be appreciated that theforegoing examples are just that—examples—and are not limitations of thepresent invention. As discussed above, the present invention could beused in conjunction with any third party, network-enabled device,regardless of the goods/services that are being provided.

In one embodiment of the present invention, as shown in FIG. 17, thewearable device may further include at least one sensor 1706 (e.g., forsensing heart data, EKG data, etc.), at least one camera 1704 (e.g., forcapturing image/video data of the first party), and/or at least onemicrophone 1702 (e.g., for capturing audio data of the first party). Notonly do these features increase flexibility (e.g., allow the first partyto speak their selection, etc.), but they can also be used to enhancesecurity. For example, audio data may be used along with voicerecognition software (e.g., on the host device, etc.) to confirm thatthe first party is who he/she claims to be. Similarly, image/video datacan be used along with facial and/or retinal recognition software (e.g.,on the host device, etc.) to confirm that the same. Sensor data (e.g.,heart rate data, EKG data, etc.) may be used to confirm that thewearable device is merely being worn at the time the mobile applicationis being used, or it too could be used to uniquely identify the firstparty. For example, the University of Toronto has developed technologythat turn one's EKG pattern into a unique key, or password that can beused for unique identification. By having possession of the mobiledevice, having the mobile device at a location where the transaction isto be facilitated, knowing the password, and having (or being able toprovide) identifiable biometric data, the mobile application can be usedto carry out the most sensitive transactions, such as banking and otherfinancial transactions. And if the mobile device includes a camera 1704,the mobile application may be configured to capture a photo of the userwhile the transaction is being carried out. The photo could then beprovided to the host, analyzed (to ensure that facial features arerecognizable, preventing the user from blocking their face, using thedevice without proper lighting, etc.), and stored together withtransaction information. Such use of the mobile device, or the camerafeature thereof, should help detour fraudulent usage of the presentinvention.

One method of using location information to facilitate a transaction isdepicted in FIG. 19. Starting at step 1900, login information isreceived at step 1902. Login information may include user name andpassword, or more secure information such as biometric data of the firstparty (e.g., data on the user's fingerprints, iris, retina, facialfeatures, speech recognition, EKG, etc.). Login information may alsoinclude a unique key, or a key unique to the mobile application and/ormobile device. The key could be either communicated or used toencode/decode and/or encrypt/decrypt communications between the mobileapplication and the host device. Once received, the login informationcan be used to locate the first party's account. The first party'saccount is an account that is linked to the mobile application, themobile device, and/or at least one payment method (e.g., the user'scredit card, debit card, etc.). The location of the mobile device isthen determined at step 1904. Location can be determined by the mobileapplication, by the host device based on information provided by themobile application, or by information provided by a third party (e.g.,the centralized device in a distributed system, etc.). Once determined,at step 1906, location is then used to identify a second party (e.g., amerchant, a store, a kiosk, etc.), and in certain embodiments, toauthenticate the user (or transaction). This may be accomplished using asecond party/location map stored on the host device or informationavailable by a third party (e.g., Google Maps™, etc.).

At step 1908, the identified party (e.g., company, etc.) is provided (ordisplayed) to the first party. At step 1910, a determination is made bythe first party as to whether the identified party is the correct party(e.g., the company that the first party wishes to do business with,etc.). If the answer is “no,” then the first party may be presented withother options at step 1914, which may include other companies that arenearby (e.g., within a predetermined distance from the mobile device).If, at step 1910, the answer is “yes,” then a pending transaction (e.g.,a transaction pending with the cashier, entered into the POS, etc.) maybe provided (or displayed) to the first party at step 1912. At step1916, a determination is made by the first party as to whether thepending transaction (as displayed) is correct. If the answer is “no,”then the first party may be presented with other options at step 1914,which may include other pending transactions, or a request to enterinformation that will allow the system to identify the correcttransaction. If, at step 1916, the answer is “yes,” then a receipt isprovided (or displayed) to the first party and/or the second party atstep 1918, ending the method at step 1920.

It should be appreciated that the present invention is not limited tothe steps illustrated in FIG. 19, and fewer, additional, or differentsteps are within the spirit and scope of the present invention. Forexample, if the transaction is a purchase of a good/service, a paymentmethod (e.g., linked to the first party's account, etc.) may be chargedbefore the receipt is provided to the first and/or second party at step1918. By way of another example, if the first party is allowed to usethe mobile application to select the transaction, then a plurality ofavailable transactions may be provided (or displayed) to the firstparty, and the first party may have an opportunity to select thetransaction prior to (or instead of) steps 1912, 1916. By way of yetanother example, if the first party is allowed to use the mobileapplication to select the transaction, then the method may alsodetermine whether the time of the selection is within a particular timewindow. For example, if a store is only open (or allowed to do businesswith the mobile application) from 9-5, then a determination may be madeas to whether the time of the transaction (e.g., selection, request,etc.) is between 9:00 AM and 5:00 PM.

By way of yet another example, additional login information may berequested by the second party after the second party has been identifiedat step 1906. For example, if the second party is a financialinstitution, the first party may be require to enter a PersonalIdentification Number (PIN) before the mobile application can be used tofacilitate a financial transaction. In this example, the PIN would needto be authenticated (e.g., by the host device, the merchant device, thefinancial institution, etc.) before the first party is allowed to select(or complete) a financial transaction. For example, if the first partyis standing in front of an ATM, the first party may be required to entertheir PIN, which may be provided to the second party (e.g., the ATM, thefinancial institution, etc.) via the host device. The second party maythen takes steps to authenticate the PIN (e.g., determine whether theprovided PIN matches a previously provided PIN), and notify the hostdevice of the results. If the PIN is not authentic, then the host devicemay notify the first party, and end the method. However, if the PIN isauthentic, then the host device may provide certain transaction optionsto the first party (e.g., via the ATM and/or the mobile device, etc.).It should also be appreciated that the present invention is not limitedto the steps being performed in the order illustrated in FIG. 19. Forexample, the mobile application could determine the device's locationbefore login information is received, options could be provided earlier,or later, etc.

It should further be appreciated that while the first party may use themobile device to provide information to the host device and/or thesecond party, any device (e.g., the mobile device, an intermediatedevice, or a network-enabled device (e.g., owned or operated by thesecond party)) can be used to provide information to the first party.For example, if at step 1914, additional information needs to beprovided to the first party, the method continues step 2000 (see FIG.20), where first content is provided on a first screen at step 2002, andsecond content is provided on a second screen at step 2004. For example,in the case of an ATM, the first screen (e.g., on the ATM) may be usedto provide a series of options to the first party (e.g., withdraw,transfer, etc.), and the second screen (e.g., on the mobile device) maybe used to provide corresponding selections to the first party (e.g.,press “1” for withdraw, “2” for transfer, etc.). At step 2006, adetermination is made as to whether a selection has been received. Ifthe answer is “no,” then the method return to step 2002. If the answeris “yes,” then at least the second screen is updated, preferablyidentifying the selection or providing the first party with a pluralityof sub-options. The first party may then be allowed to acknowledge theselection at step 2010. If, at step 2010, the answer is “no,” then themethod may return to step 2002. If, at step 2010, the answer is “yes,”then a receipt may be provided to the first and/or second party at step2012, ending the method at step 2016.

Again, it should be appreciated that the present invention is notlimited to the steps illustrated in FIG. 20, and fewer, additional, ordifferent steps are within the spirit and scope of the presentinvention. For example, if the transaction is a purchase of agood/service, a payment method (e.g., linked to the first party'saccount, etc.) may be charged before the receipt is provided to thefirst and/or second party at step 2012. The method may also determinewhether the time of the selection is within a particular time window,may update the first screen (instead of or in addition to the secondscreen) in step 2008, and certain steps (e.g., 2002 and 2010) may berepeated if additional selections are required (e.g., to drill down)(e.g., at an ATM, the first party may select “withdraw,” followed by“checking,” followed by “$20,” etc.).

As discussed above, the host may store (or have access to) (e.g., via alocally and/or remotely located memory device or database) a map (e.g.,look-up table, etc.) that can be used to identify (or look-upinformation related to) a user's account, a second party (e.g.,merchant), or a particular transaction. Such a map is shown in FIG. 21,where information is linked together using fields (e.g., rows, columns)that are related or linked to one another, using, e.g., spreadsheet ordatabase technology.

For example, a First User 2102 a (e.g., User 1, which may be identifiedby a unique identifier, etc.) may be linked to User Account Information2104 a (e.g., name, address, phone number, email address, preferences,etc.), User Login Information 2106 a (e.g., login name, password, etc.),User Biometric Data 2108 a (e.g., fingerprint, retina, iris, facial,voice, EKG, etc.), User Payment Information 2112 a (e.g., credit card,debit card, bank account, host account, preferences on which account touse (e.g., default account), etc.), and User Authorized LocationInformation 2112 a (e.g., at least one user location (e.g., X, Y, and/orZ coordinates (e.g., GPS coordinates, such as latitude, longitude and/oraltitude), address, city, state, zip code, etc.) (e.g., the user's home,etc.), proximity data (e.g., within the user location, within a one mileradius from the user location, etc.). Similar data can be stored onother users (e.g., User n, 2102 b).

As discussed above, the User Authorized Location Information 2112 a maybe used in conjunction with location information provided by the mobileapplication to determine whether the user (including the mobile device)is at an authorized location. For example, if the User AuthorizedLocation Information 2112 a includes the user's home address and aproximity radius of a one mile, then the user may be determined to be atan authorized location (e.g., for remote transactions) if the user (orthe user's mobile device) is within a one mile radius of the user's homeaddress, or GPS coordinates associated therewith, when a transaction isbeing carried out. By way of another example, if the User AuthorizedLocation Information 2112 a includes the user's home zip code and aproximity value of “within the user location,” then the user may bedetermined to be at an authorized location if the user (or the user'smobile device) is within the user's zip code, or GPS coordinatesassociated therewith, when a transaction is being carried out.

Similar information can also be stored on a particular merchant. Forexample, a First Merchant 2102 c (Merchant 1, which may be identified bya unique identifier, etc.) may be linked to Merchant Account Information2104 c (e.g., name, address, phone number, website, email address,goods/services offered for sale, pending orders, etc.), at least oneMerchant Time Window 2106 c (e.g., hours of operation, etc.), a MerchantRemote Access Policy 2108 c (e.g., whether goods/services can bepurchase remotely, e.g., from the user's home, etc.), Merchant LocationInformation 2110 c (e.g., at least a first merchant location (e.g., X,Y, and/or Z coordinates (e.g., GPS coordinates, such as latitude,longitude and/or altitude), address, city, state, zip code, etc.),proximity data (e.g., within the first merchant location, within onehundred feet from the first merchant location, etc.), etc.), andMerchant Authorized Location Information 2112 c (e.g., at least a secondmerchant location (e.g., X, Y, and/or Z coordinates (e.g., GPScoordinates, such as latitude, longitude and/or altitude), address,city, state, zip code, etc.), proximity data (e.g., within two feet fromthe second user location, etc.), etc.). Similar data can be stored onother merchants (e.g., Merchant n, 2102 d).

As discussed above, the Merchant Location 2110 c may be used along withlocation information provided by the mobile application to identifyMerchant 1. For example, if the Merchant Location 2110 c includes anaddress of a store operated by Merchant 1 and a proximity radius of onehundred feet, and the user (or the user's mobile device) is at alocation within a one hundred foot radius of the store's address (e.g.,the location information provided to or by the mobile application iswithin a one hundred foot radius of the store's address), then Merchant1 will be identified by the host device, and information on Merchant 1(e.g., Merchant Account Information 2104 c, etc.) will be provided tothe mobile application and displayed to the user. This same informationcan also be used to authenticate the user or transaction. In otherwords, if the user (or the user's mobile device) is within a one hundredfoot radius of the store's address, then the user (or the user's mobiledevice) may be considered to be at an authorized location. In otherembodiments, other information can be used to authenticate the user ortransaction. For example, if the Merchant Authorized LocationInformation 2112 c includes a proximity radius of ten feet (e.g.,identifying (roughly) the perimeter of the store, etc.), then the userwill only be considered to be at an authorized location if the user iswithin a ten foot radius of the store's address, or associated GPScoordinates. It should be appreciated that while proximity has beenexemplified using a radius, the present invention is not so limited, andany method of identifying a particular area (e.g., using plural GPScoordinates, an X proximity value, a Y proximity value, etc.) is withinthe spirit and scope of the present invention.

The map 2100 may also store information on individual transactions. Forexample, a First Transaction 2102 e (Transaction 1, which may beidentified by a unique identifier, etc.) may be linked to a Merchant2104 e (e.g., a particular merchant, such a Merchant 1, a particularuser, such as User n, etc.), a User 2106 e (e.g., a particular user,such as User 1, etc.), a Transaction Date 2108 e (e.g., a date of thetransaction, etc.), a Description 2110 e (e.g., a description of thetransactions, such as goods/services, etc.), and Payment Information2112 e (e.g., cost of the transaction, a payment method used to pay forthe transaction, etc.). Similar data can be stored on other transactions(e.g., Transaction n, 2102 f).

It should be appreciated that the present invention is not limited tothe map depicted in FIG. 21. A database having additional, fewer, ordifferent fields is within the spirit and scope of the presentinvention. For example, payment information could be stored by themerchant, and not processed (or stored) by the host device. By way ofanother example, the transaction records may further include at leastone image of the transaction. Such an image could be provided by themerchant (e.g., using security cameras operated by the merchant) or theuser (e.g., using a camera on the mobile device) and linked togetherwith the transaction, making it available upon request.

Having thus described several embodiments of a system and method forusing at least location information to facilitate a transaction, itshould be apparent to those skilled in the art that certain advantagesof the system and method have been achieved. It should also beappreciated that various modifications, adaptations, and alternativeembodiments thereof may be made within the scope and spirit of thepresent invention. The invention is solely defined by the followingclaims.

What is claimed is:
 1. A method for using at least location information to facilitate a transaction between a first party and a second party, comprising: opening an application on a mobile device, said application being in communication with a host device via a wide area network (WAN); receiving login information from said first party, said login information being used to identify an account for said first party; determining a location of said mobile device, said location being provided to said host device via said WAN and used to identify said second party; receiving transaction and authentication data from said first party, said transaction data including a request for said second party to at least one of perform a particular action for said first party and provide a particular item to said first party; and displaying first and second information to said first party, wherein each one of said first and second information includes data on at least one of said first party, said request made by said first party, said second party, and transactions offered by said second party; wherein said request is at least one of performed and provided by said second party only if said authentication data is authenticated, said first information is displayed on a first display means, said second information is displayed on a second display means, said first information is displayed simultaneously with said second information, and said first display means is separate and distinct from said second display means.
 2. The method of claim 1, wherein said step of receiving login information from said first party comprises receiving at least a user name, a password associated with said account, and at least one biometric of said first party.
 3. The method of claim 2, wherein said at least one biometric of said first party comprises at least one of a fingerprint of said first party, and image of said first party, and audio from said first party.
 4. The method of claim 1, wherein said step of determining a location of said mobile device comprises using at least data acquired from global positioning satellites (GPS) to determine said location.
 5. The method of claim 1, wherein said authentication data comprises a personal identification number (PIN) associated with at least one of said account, said first party, and said second party.
 6. The method of claim 1, wherein said step of displaying first and second information comprises displaying said first information on a display portion of said mobile device and displaying said second information on a display portion of a network-enabled device operated by or associated with said third party.
 7. The method of claim 1, wherein said step of displaying first and second information comprises displaying said first set of information on a first display portion of said mobile device and displaying said second information on a second display portion of said mobile device.
 8. The method of claim 1, wherein said data on said request made by said first party includes at least one of asking said first party to confirm said request, notifying said first party that said request has been received, notifying said first party that said request will be performed or provided by said second party, and notifying said first party that said request has been performed or provided by said second party.
 9. The method of claim 1, wherein said request is one of performed and provided by said second party only if said authentication data is authenticated and a time that at least one of said transaction and authentication data is received is within a predetermined time window.
 10. The method of claim 1, further comprising the step of instructing said second party to at least one of perform said particular action and provide said particular item only if said host device determines that said authentication data corresponds to previously provided authentication data.
 11. The method of claim 1, further comprising the step of providing said authentication data to said second party, said third party at least one of performing said particular action and providing said particular item only if said authentication data corresponds to previously provided authentication data.
 12. A system for using at least location information to facilitate a transaction between a first party and a second party, comprising: A mobile device in communication with a host device via a wide area network (WAN) and comprising at least one memory device for storing an application adapted to perform the steps of: receiving login information from said first party, said login information being used to identify an account for said first party; determining a location of said mobile device, said location being provided to said host device via said WAN and used to identify at least said second party; receiving transaction and authentication data from said first party, said transaction data including a request for said second party to at least one of perform a particular action for said first party and provide a particular item to said first party; and displaying first information to said first party on said mobile device, wherein second information is displayed simultaneously with said first information on a separate display device, and each one of said first and second information includes data on at least one of said first party, said request made by said first party, said second party, and transactions offered by said second party; wherein said request is at least one of performed and provided by said second party only if said authentication data is authenticated by at least one of said host device and said second party.
 13. The system of claim 12, wherein said location of said mobile device is determined using at least data acquired from global positioning satellites (GPS).
 14. The system of claim 12, wherein said authentication data comprises a personal identification number (PIN) associated with at least one of said account, said first party, and said second party.
 15. The system of claim 12, wherein said request is at least one of performed and provided by said second party only if said authentication data is authenticated and a time that at least one of said transaction and said authentication data is received is within a predetermined time window.
 16. The system of claim 12, further comprising said host device, wherein said host device is configured to authenticate said authentication data by determining whether said authentication data matches data that is stored on a memory portion of said host device, said stored data being one of data previously provided by said first party, data received from said second party, and data received from a third party.
 17. The system of claim 12, further comprising a network-enabled device operated by or associated with said second party, said network-enabled device being in communication with said host device via said WAN and comprising a display device for displaying said second information.
 18. The system of claim 17, wherein said network-enabled device comprises one of an Automated Teller Machine (ATM), an Automated Pay Station (APS), a smart monitor, a smart television, a television Set Top Box (STB), and a smart gaming device.
 19. A method for using at least location information to facilitate a transaction between a first party and a second party, comprising: opening an application on a mobile device, said application being in communication with a host device via a wide area network (WAN); determining a location of said mobile device, said location being provided to said host device via said WAN and used to identify said second party; receiving transaction data from said first party, said transaction data including a request for said second party to at least one of perform a particular action for said first party and provide a particular item to said first party; displaying first information on a display portion of said mobile device, said first information comprising data on at least one of said first party, said request made by said first party, said second party, and transactions offered by said second party; and displaying second information on a display portion of a network-enabled device, said second information comprising data on at least one of said first party, said request made by said first party, said second party, and transactions offered by said second party; wherein said request is at least one of performed and provided by said second party if said transaction data is at least one of authenticated and confirmed by at least one of said host device and said second party.
 20. The method of claim 19, wherein said network-enabled device comprises one of an Automated Teller Machine (ATM), an Automated Pay Station (APS), a Set Top Box (STB), a network-enabled monitor, a network-enabled television, and a network-enabled gaming device. 